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V. 



SUMMARY OF CLAIMED SUBJECT MATTER 



The following summary correlates claim elements to embodiments described in the 
application specification, but does not in any manner limit claim interpretation. Rather, the 
following summary is provided only to facilitate the Board's understanding of the subject matter 
of this appeal. The elements of the claims presented in this section have been bolded and 
italicized for convenient identification. 

Aspects of the present invention provides "a method and system for intelligently selecting 
a single video stream from video streams originating from multiple participants of a multimedia 
network conference and sending the selected video stream to a client for viewing."* Application, 
page 3, lines 11-15. "In accordance with the invention, periodically, each of the participants is 
assigned a weight that is dynamically determined" 3 (Application, page 12, line 27 to page 13, 
line 3) as "a function of the participants' activity state variables . . . and a set of tunable 
parameters called 'participant selection control parameters.'"* Application, page 17, lines 3-6. 
"The participant with the highest weight among all the participants is then selected for viewing 
by the client, i.e., the video stream from that participant is sent to the client." 4 Application, page 
3, lines 22-25. 

Claim 10 is directed to a system for conducting a multimedia conference!" See 
Application, page 3, lines 11-14 ("the present invention provides a . . . system for intelligently 
selecting a single video stream from video streams originating from multiple participants of a 
multimedia network conference."). The system includes a plurality of participants each 
providing multimedia conferencing data including a video signal and an audio signal. For 
example, the embodiment of the invention illustrated in Figure 2 of the present application 
"shows two multicast-capable clients 102, 104 connected to the multicast network 100. " 6 
Application, page 10, lines 9-11. Each of the two multicast clients provides outgoing "audio and 



* Application, page 3, lines 11 15. 

Application, page 12, line 27 to page 13, line 3. 
a Application, page 17, lines 3 6. 
4 Application, page 3, lines 22 25. 

Sec Application, page 3, lines 11 1 4 ("the present invention provides a . . . system for intelligently selecting a 
single video stream from video streams originating from multiple participants of a multimedia network 
conference.") 

6 Application, page 10, lines 9 11. 
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video streams 1 10 ... for delivery to all the other participants." 7 Application, page 10, lines 19- 
21. The system of claim 10 also includes a client in conference with the participants, and is 
capable of receiving the video signal corresponding to one of the participants at a time. For 
example, the embodiment of the invention illustrated in Figure 2 includes a client (e.g., 1 12, 1 14) 
who "can only receive the video stream of one participant at a time."* Application, page 12, 
lines 26-27; see also, page 9, lines 25-27. 

The system of claim 10 includes a bridge server connected to the participants through a 
network and having a point-to-point connection with the client. As described by the 
specification, embodiments of the bridge server allow "a client (e.g., client 1 12) that is not 
multicast-capable or multicast-connected [to] participate in a network conference."" 9 
Application, page 11, lines 9-11. A s explained by the present application in reference to FIG. 2, 
"the bridge server 120 is connected to the multi-cast network 100" 40 (Application, page 1 1 , lines 
11-12) and "functions as a proxy for connecting the client 1 12 to a multimedia conference. " u 
Application, page 11, lines 14-15. Specifically, "[w]hen the client 112 wants to participate in a 
multimedia network conference, it places a point-to-point call to the bridge server 120." 43 
Application, page 11, lines 15-18. A ccordingly, "[t]he bridge server, on behalf of the client, then 
joins the multicast group defining the conference." 4 * Application, page 11, lines 18-20. The 
bridge server sends a video stream to the client which "contains only one video substream 
representing only one of the participants." 44 Application, page 12, lines 16-19. 

In order to select the video stream for sending to the client from the plurality of video 
streams originating from the participants of the network conference, the system includes a 
participant state table and a participant selection control parameter stored in memory. The 
participant state table indicates] an activity state variable for each participant 44 ' See 
Application, page 13, lines 21-23; page 14, lines 24-27; Figure 4. The activity state variable 
include fesj values and statistics associated with the participant's video signal and audio 



? Application, page 10, lines 19 21. 

8 Application, page 12, lines 26 27; See also, page 9, lines 25 27. 

9 Application, page 1 1 , lines 9 11. 
" Application, page 11, lines 1 1 12. 
u Application, page 11, lines 1 4 15. 
w Application, page 11, lines 15 18. 
w Application, page 11, lines 18 20. 
44 Application, page 12, lines 16 19. 

^ See Application, page 13, lines 21 23; page 11, lines 21 27; Figure 4. 
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signal,^ Application, page 14, lines 25-27) "such as whether the participant is being shown to 
the client, how long the participant has been shown or not shown, etc."^ Application, page 3, 
lines 18-20. "The activity states of [each] participant are then used in the weight assignment 
process" discussed below. Application, page 13, lines 14-16. 

The participant selection control parameter is received when the multimedia conference 
is set up^ (Application, page 19, lines 8-9) f or tuning a video switching stream behavior^ (see 
Application, page 17, lines 6-9; page 19, lines 5-6) during the conference. As shown in Table 1 
of the present application, each received participant selection control parameter has a 
constant/fixed value which affects the outcome of the weight computation discussed below 30 . 
Application, page 17, lines 3-6. 'TTIhe values of the control parameters can be tailored to obtain 
desired video stream switching behavior ... to suit the nature of format of the network 
conference." Application, page 19, lines 4-8. Thus, "|"t"|he values of the parameters may be 
specified when the conference is set up," but do not change during the network conference- 
Application, page 19, lines 8-9. A ccordingly, each participant selection control parameter has 
a static display constraint on a selection of a video signal^ Application, page 17, lines 3-6. 

For example, the exemplary participant selection control parameters in Table 1 include a- 
"Minimum Shown Time" and a "Minimum Shown Time If Active." The "Minimum Shown" 
Time" control parameter specifies the minimum "period of time (8 seconds) that a selected 
participant's video stream will be displayed on the client stream. 33 The "Minimum Shown Time 
If Active" control parameter specifics the minimum period of time (15 seconds) that a selected 
participant's video stream will bo displayed on the client screen if the participant is still talking 
for this period of time." 3 * These two parameters "help to prevent a flurry of abrupt jumps from 
one participant to another. For example, if these parameters are not used and the switching is 
based only on which participant happens to be making the loudest sound, then the screen image 
may bo switched back and forth too quickly and too frequently between the talking participants, 



u Application, page 11, lines 25 27. 
w Application, page 3, lines 18 20. 
^ Application, page 19, lines 8 9. 

w See Application, page 17, lines 6 9; page 19, lines 5 6. 
M Application, page 17, lines 3 6. 
a Application, page 17, lines 3 6. 

Application, page 18, Table 1, Row 2. 
33 Application, page 18, Table 1, Row 3. 
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resulting in an unpleasant client experience.'^ -an "Active Cycle Time" and a "Complete Active 
Cycle Time." The "Active Cycle Time" control selection parameter specifies 'Ttlhe time period 
that an actively talking participant's video stream is displayed by the client if only this participant 
is talking. Application, page 18, Table 1. The exemplary value in Table 1 of the "Active Cycle 
Time" control parameter is 300. This value does not chance during the conference. Instead, the 
video stream switching behavior is further controlled by the "Complete Active Cycle Time" 
parameter which is a "control that helps enforce Active Cycle Time for participants." 
Application, page 19, Table 1. The exemplary value in Table 1 of the "Complete Active Cycle 
Time" control parameter is 7000. 

During the conference, the bridge server receivfesj simultaneously the multimedia 
conferencing data including the video signal from each of the participants ^ (Application, 
page 11, lines 21-26; See also Figure 3) and updatefsj the activity state variable stored in the 
memory for each participant in the participant state table according to changes in a data 
information and a control information of the participant's video signal and audio signal^ 
Application, page 13, lines 1 1-23 ("In this embodiment, several participant events are defined 
and used to update activity states of the participant. The activity states of the participant are then 
used in the weight assignment process. In this regard, the multimedia streams received by the 
bridge server from the multicast group include both data and control information. In response to 
changes in both of these pieces of information, the multicast conference server 122 generates the 
participant events. As a part of handling these events, the multicast conference server 122 
updates a participant state table 150 associated with the conference."). The bridge server 
periodically comput[es] a weight of[] each participant based on the activity state variable of[] 
each participant and the participant selection control parameter. ^ Application, page 17, lines 
3-6; page 13, lines 1-2. 



24 Application, page 21, lines 12 19. 

Application, page 11, lines 21 26; See also Figure 3. 
26 Application, page 13, lines 1 1 23 ("In this embodiment, several participant events are defined and used to update 
activity states of the participant. — The activity states of the participant are then used in the weight assignment 
process. In this regard, the multimedia streams received by the bridge server from the multicast group include both 
data and control information. In response to changes in both of these pieces of information, the multicast conference 
server 122 generates the participant events. As a part of handling these events, the multicast conference server 122 
updates a participant state table 150 associated with the conference ."). 
M Application, page 17, lines 3 6; page 13, lines 1 2. 
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In particular, the bridge server assignfsj a predetermined weight to at least one of the 
plurality of participants for a duration specified by the static display constraint. For example, 
fer-if "the participant is being shown (step 1 8 4 ), it is determined whether the 
SocsSincoLastStartodShowing value is loss than and talking but has been shown for longer than 
the Minimum Shown Time If Active (step 198), then it is determined (step 192). If so, the 
weight is set to be MAXWEIGHT (step 191) 200) whether the value of 

SecsSinceLastStartedShowing is less than Active Cycle Time , which-4 s functions roughly as an 
upper limit of how long a-ve w participant who is continuously talking should be continuously 
shown. If the participant has been shown for less than Active Cycle Time, the weight is set (step 
202) to Complete Active Cycle Time, which is a relative large value, to ensure enhance the 
likelihood that-thi s the active participant will be selecte d. This guarantees that a participant, once 
selected for viewing, will bo shown for at least the Minimum Shown Time (e.g., 8 soconds)." 3 ^ 
again." Application, page 21, line 20 - page 22, line 3. 

After the bridge server has computed a weight for the participants, the bridge server 
identify fiesj a participant having a highest weight among the participants, and selectfsj . . . the 
video signal corresponding to the identified participant having the highest weight for 
transmission to the client for viewing ^ Application, page 3, lines 22-25; page 16, lines 16-19; 
page 16, line 24 to page 17, line 1. 

Claim 24 is directed to a method for selecting one video signal from a plurality of video 
signal for forwarding to a client. m Application, page 12, lines 10-12. Each video signal 
correspond[s] to a participant of multiple participants of a multimedia conference.^ 4 " Application, 
page 12, lines 4-6. For example, "during the conference the bridge server receives a video and 
audio stream from the client . . . Tandl also receives the video and audio data from the other 
participants." Application, page 11, lines 21-26. "In one implementation, . . . multicast 
conference server . . . receives one audio stream 136 and one video stream for the conference 
from the multicast network. The audio stream 136 contains a mixture of audio data from the 
other participants. The video stream 138 contains several substreams Te.g., signals], each 
carrying video data from one participant." Application, page 11, line 27-page 12, line 6. "These 



38 Application, page 20, lines 19 26; Sec also Figure 6. 

29 Application, page 3, lines 22 25; page 16, lines 16 19; page 16, line 2 4 to page 17, line 
m Application, page 12, lines 10 12. 
M Application, page 12, lines 4 6. 
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substreams are sent to a bridge service component 126, which is responsible for selecting one of 
the substreams for forwarding to the client." Application, page 12, lines 9-12. 

The method includes receiving a participant selection control parameter for the 
multimedia conference when the conference is being set up.* 3 Application, page 19, lines 8-9. 
The participant selection control parameter hafsj a static display constraint of selecting the 
one video signal* * Application, page 17, lines 3-6. For example, as discussed explained above, 
the exemplary participant selection control parameter in Table 1 , Active Cycle Time, functions 
roughly as an upper limit of how long a participant who is continuously talking should be 
continuously shown. Application, page 21, line 20 - page 22, line 3. 

Additionally, the participant selection control parameters in Table \-, include "Minimum 
Shown Time" and "Minimum Shown Time If Active" which specify minimum times for showing 
a participant's video stream.* 4 Application, page 18, Table 1, Rows 2-3. Specifically, the 
"Minimum Shown Time" control parameter specifies the minimum period of time (8 seconds) 
that a selected participant's video stream will be displayed on the client stream. Application, 
page 18, Table 1, Row 2. The "Minimum Shown Time If Active" control parameter specifies the 
minimum period of time (15 seconds) that a selected participant's video stream will be displayed 
on the client screen if the participant is still talking for this period of time." Application, page 
18, Table 1, Row 3. These two parameters "help to prevent a flurry of abrupt jumps from one 
participant to another. For example, if these parameters are not used and the switching is based 
only on which participant happens to be making the loudest sound, then the screen image may be 
switched back and forth too quickly and too frequently between the talking participants, resulting 
in an unpleasant client experience." ^ Application, page 21, lines 12-19. 

The method of claim 24 includes receiving simultaneously multimedia conferencing 
data . . . that includ[es] the plurality of video signals from the participants*^ (Application, page 
11, lines 21-26; See also Figure 3) and monitoring participant events of the multimedia 
conference** . Application, page 3, lines 16-20. The participant events [are] generated in 
response to changes in the data information and the control information of the multimedia 

33 Application, page 19, lines 8 9. 
Application, page 17, lines 3 6. 

34 Application, page 18, Table 1, Rows 2 3 . 
34 Application, page 21, lines 12 19. 

36 Application, page 11, lines 21 26; Sec also Figure 3. 
w Application, page 3, lines 16 20. 
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conferencing data Application, page 13, lines 11-23 ("In this embodiment, several participant 
events are defined and used to update activity states of the participant. The activity states of the 
participant are then used in the weight assignment process. In this regard, the multimedia 
streams received by the bridge server from the multicast group include both data and control 
information. In response to changes in both of these pieces of information, the multicast 
conference server 122 generates the participant events. As a part of handling these events, the 
multicast conference server 122 updates a participant state table 150 associated with the 
conference."). For example, the participant events may include "NewSub Stream" for indicating 
that the participant stated sending video and "SubStreamRemoved" for indicating that the 
participant stopped sending video ^ Application, page 13, lines 26-27. 

Additionally, the method of claim 24 includes providing a participant state table . . . 
indicating an activity state variable for each participant of the multimedia conference 4 ® (see 
Application, page 13, lines 21-23; page 14, lines 24-27; Figure 4) and updating at least one of 
the activity state variables in the participant state table according to the participant events. 
The activity state variable includ[es] values and statistics associated with the participant's 
multimedia conference data, 4 * (Application, page 12, 27- page 13, line 5 ("In accordance with 
the invention, periodically, each of the participants is assigned a weight that is dynamically 
determined based on the participants' conferencing activity state data, which in turn are updated 
according to participant events associated with the video and audio streams." Emphasis 
added); see also. Application, page 14, lines 25-27) "such as whether the participant is being 
shown to the client, how long the participant has been shown or not shown, etc." 43 Application, 
page 3, lines 18-20. 

The method of claim 24 includes periodically computing a weight for each of the 
participants based on the activity state variable of[] each participant and the participant 



Application, page 13, lines 1 1 23 ("In this embodiment, several participant events are defined and used to update 
activity states of the participant. — The activity states of the participant are then used in the weight assignment 
process. In this regard, the multimedia streams received by the bridge server from the multicast group include both 
data and control information. In response to changes in both of these pieces of information, the multicast conference 
server 122 generates the participant events. As a part of handling these events, the multicast conference server 122 
updates a participant state table 150 associated with the conference ."). 
39 Application, page 13, lines 26 27. 

49 Sec Application, page 13, lines 21 23; page 1 4 , lines 2 4 27; Figure 4 . 

41 Application, page 1 4 , lines 25 27. 

42 Application, page 3, lines 18 20. 
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selection control parameter^ (Application, page 17, lines 3-6; page 13, lines 1-2) and 
identifying a participant having a highest weight among the participants. 44 Application, page 3, 
lines 22-25; page 16, lines 16-19. A ccordingly, the [] video signal corresponding to the 
participant having the highest weight is selectfedj from the received multimedia conference 
data . . . for viewing by the client 4 ^ Application, page 3, lines 22-25; page 16, line 24 to page 
17, line 1. 



43 Application, page 17, lines 3 6; page 13, lines 1 2. 

44 Application, page 3, lines 22 25; page 16, lines 16 19. 

^ Application, page 3, lines 22 25; page 16, line 21 to page 17, line 1. 
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REMARKS 

Applicants submit that the Appeal Brief, as corrected by the Amended Summary of 
Claimed Subject Matter pursuant to MPEP § 1205.03(B), is in compliance with 37 C.F.R. 41.37 
and respectfully request a substantive evaluation of the issues presented. In particular, as 
requested by the Office, Applicants have included page and line numbers and examples 
supporting the limitation in claim 10 which recites "said participant selection control parameter 
being received when the multimedia conference is set up, said participant control selection 
parameter having a static display constraint on a selection of a video signal." Additionally, 
Applicants have included page and line numbers and examples supporting the limitation in claim 
24 which recites "each video signal corresponding to a participant of multiple participants of a 
multimedia conference" and "said participant events associated with the multimedia 
conferencing data of the participants." 

Applicants do not believe a fee is due. If, however, the Commissioner determines 
otherwise, other deficient fees may be charged during the entire pendency of this application to 
Deposit Account No. 19-1345. 



Respectfully submitted, 

/Robert M. Bain/ 

Robert M. Bain, Reg. No. 36,736 
SENNIGER POWERS LLP 
100 North Broadway, 17th Floor 
St. Louis, Missouri 63102 
(314) 345-7000 



RMB/NAS 
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